[NEW] オンプレでMediaLiveが動く!AWS Elemental MediaLive Anywhereが登場しました
はじめに
清水です。AWSのライブビデオ処理サービスであるAWS Elemental MediaLiveに新機能が加わりました!その名も AWS Elemental MediaLive Anywhere 、オンプレミスでライブ動画エンコーディングを行いながら、その管理をクラウドで行うというものです。2024/09/11付けでAWS for M&E Blogに新機能リリースエントリとして投稿されていました。What's New at AWSには2024/09/12付けでポストされています。
- Introducing AWS Elemental MediaLive Anywhere: Cloud-controlled live video encoding on your own infrastructure | AWS for M&E Blog
- Announcing AWS Elemental MediaLive Anywhere for live video encoding on your own hardware - AWS
さらにMediaLiveのサービスページ、FeaturesにもMediaLive Anywhereのページが追加されています!
本エントリではこのMediaLiveの新機能であるMediaLive Anywhereについて、AWSのブログポストやドキュメントなどからわかることをまとめてみました。またMediaLive Anywhereの関連リソースを作成し動作の雰囲気をつかんでみています。AWSとして4つ目となるAnywhereなサービス・機能ですが[1] 、内部的にはAmazon ECS Anywhereを使ってオンプレミスリソースを管理しているようでした。
MediaLive Anywhreとは
オンプレミスでのライブ動画処理を考える
オンプレミス上でライブ動画処理を行うことを考えてみます。第一の候補となるのがオンプレミスのエンコーディングアプライアンス製品ではないでしょうか。AWS Elemental LiveというAWS Elemental Appliances and Softwareの製品の一つがありますね。まずはこのElemental Liveについてざっと確認しておきましょう。
初見だと少し混乱しそうな名称ではあるのですが、「AWS Elemental MediaLive」と「AWS Elemental Live」は別サービス・製品です[2] 。そもそも、AWS Elementalと名の付くサービスはAWSが2015年9月に買収したElemental Technologies社にルーツがあります。Elemental Liveについても、もともとはElemental Technologies社のライブエンコーダ製品でした。WikipediaのAWS Elementalのページによると2010年4月にリリースされた製品ということです。当時はまだクラウドという考えが広まる前で、ライブ動画処理といえば当然オンプレミスで対応していたかと思います。そしてElemental Technologies社がAWSに買収されたあとも、AWS Elemental Liveとして製品開発が進められています。2024年4月には最新のL900シリーズがリリースされました。
上記ブログエントリで製品の写真が確認できますが、ハードウェアとしては1Uサイズのサーバです。以下のページではアプライアンスの仕様として、例えば背面にどんなポートがあるかといった情報が確認できます。型番により様々ではありますが、例えばL984AE-Uでは背面にSDIの口があることがわかります。
オンプレミス側のほかの映像機器、例えばスイッチャーなどからの映像を信号としてそのままElemental Liveに入力することができます。またライブ動画処理した結果をオンプレミスのサーバなどロカールネットワーク内に連携する、といったユースケースはElemental Liveの非常に得意とするところです。対して、クラウドという考え方が広まった現在からすると、オンプレミスのアプライアンス製品ということでその運用管理などのコストがクラウドと比べると多く発生します。ハードウェアの維持やソフトウェアの最新化がなどが必要になります。
また個人的には、アプライアンス製品ということで検証などちょっとだけ触ってみるというのが難しい印象があります。(筆者はElemental Liveを実際に触ったことがありません。)最近はAWSのDocumentationページにUser guidesなどが公開されるようになりましたが、例えばWebに公開されている情報や実際に使ってみた情報なども少ないことから、使い方の習得などに時間がかかってしまうのではないでしょうか。
クラウドでライブ動画処理を行うAWS Elemental MediaLiveの利用も考えてみましょう。Elemental Liveと比べると、ハードウェア・ソフトウェアともに完全マネージドであることは大きな利点ですよね。またクラウドサービスとしてすぐに使えることも利点であるかと考えます。User GuideはじめWebに公開されている情報も多いですよね。
ですが、SDIなどオンプレミス環境でやり取りしている映像をそのままクラウドで使用できるわけではありません。オンプレミスからクラウドに映像を打ち上げる必要があります。また処理を行った動画の連携先がクラウドであればよいのですが、オンプレミスのサーバなどと連携する場合は追加の通信が発生します。このようなラウンドトリップを考慮すると、入出力がともにオンプレミス側であれば、わざわざクラウドに打ち上げずライブ動画処理自体もオンプレミス側で行ったほうが効率が良さそうです。
エンコードはオンプレで処理しながら管理はクラウドで
オンプレでのライブ動画処理、Elemental LiveとMediaLiveそれぞれのメリットデメリットを比較してみると、「エンコーディングはオンプレミスの機器で処理しながら、MediaLiveのようなクラウドらしい管理をしたい。」、「MediaLiveを使いながら、オンプレミス側で完結するならクラウドに映像を打ち上げずに処理をしたい。」といった要望があがります。これらを実現するのがMediaLive Anywhereで、MediaLiveで使用されているのと同じブレードキャストグレードの動画エンコーディングエンジンがオンプレミスのハードウェアにデプロイされます。つまり、MediaLiveがオンプレミス機器で動きます。ライブ動画処理(いわゆるデータプレーン)はオンプレミス側で行い、操作や管理、監視など(いわゆるコントロールプレーン)はクラウド側のMediaLiveで行うという、MediaLiveの機能の一つとなります。
ユースケースは上記のように、SDIなどオンプレミスに固定されたビデオソースがある場合、また送信先がローカルネットワークにある場合などが挙げられます。すでにオンプレミスにハードウェアがありこの資源を活かしなが、ライブビデオワークフローを今後クラウドに移行していきたい、といったい場合にもMediaLive Anywhereを導入することで今後の移行が容易になります。
コントロールはAWSマネジメントコンソールから行うかたちです。関連リソースにMediaLive Anywhere用のものもありますが、InputやChannelといったMediaLiveのリソースやその設定内容は変わりません。個人的には、検証などがしやすく、また情報なども多いMediaLiveの操作体系でオンプレミス上のライブ動画処理が行えることは非常に大きいのではないかと考えます。
なお、ライブビデオワークフローが完全にオンプレミスである場合は、引き続きAWS Elemental Liveアプライアンスとソフトウェアが適切な選択肢のままである、とアップデートブログ(Introducing AWS Elemental MediaLive Anywhere: Cloud-controlled live video encoding on your own infrastructure | AWS for M&E Blog)で述べられています。
ハードウェアにElemental Liveを利用することもできる!
オンプレミスでMediaLiveが動作するというMediaLive Anywhere、ハードウェアのスペックなど動作要件が気になりますよね。ドキュメントなどを確認した限り、現時点で推奨環境などは明記されていませんでした。代わりにAWSとしては、MediaLive Anywhereで使用するハードウェアをAWSパートナーから購入することを推奨しています。これらAWSパートナーはハードウェアの組み立て、統合、テスト、サポートなどを行いMediaLive Anywhereで使用できる状態を保証しているとのことで、MediaLive Anywhere機能ページでは以下4社が紹介されています。
- Bridge Digital Inc
- Insys Video Technologies
- LOGIC FAIRNESS & KOMPETENZ
- NOMAD MEDIA
ハードウェアにはCPUやメモリといったスペックのほか、SDIなどで映像信号を受けるビデオI/Oカードなども必要になります。ドライバの有無や機器の相性などもあるかと思うので、すでにテスト済みの構成などがAWSパートナーから得られるのは大きいかと思います。
なお、既存のAWS Elemental Live L800およびL900シリーズアプライアンスをMediaLive Anywhereのハードウェアとして利用することもできるようです。これらはわずか数ステップでMediaLive Anywhereに移行できるとのことで、今後クラウドに移行したいと考えている場合に嬉しいポイントではないでしょうか!
MediaLive Anywhereのサービス料金は従量課金
MediaLive Anywhereの料金についても確認しておきましょう。こちらもMediaLive Anywhere機能紹介ページに記載されています。(MediaLiveのページには現段階で記載がありません。)
MediaLive Anywhereによって管理されるオンプレミスインスタンスで実行されているChannelに対して、時間単位でサービス料金が発生します。長期契約や前払いが必要ない点は通常のMediaLiveと同じです、これは嬉しいポイントですよね。またコーデックと最高出力解像度によって料金が異なる点はMediaLiveと同様ですが、入力や出力の数によらず、実行しているChannelによって料金が決まる点に注意しましょう。
オンプレミスでElemental Liveなどアプライアンス製品を利用する場合、おそらくハードウェアとソフトウェア含めた買い切りの料金体系になるのではないでしょうか。(筆者はElemental Liveの購入経験がなく、また料金詳細も知らないためあくまで推測ではあります。)使用する最大量を見越して購入しておく必要があり、アイドル状態のリソースに対しては無駄が発生してしまいます。MediaLive Anywhereのサービス料金は従量課金ですので、コスト効率が良くなることが期待できます。
なおこれらMediaLive Anywhereの料金について、ハードウェア費用は含まれていません。それでも不要なライセンスを購入しなくてよいなど、ソフトウェア部分が従量課金になることのメリットは大きいと考えます。またAWSパートナーからのハードウェア購入の際に、買い切りや長期のリース契約などが前提となるのではなく、短期間の利用などある程度柔軟な入手方法が提供されるとうれしいですよね
追加料金から垣間見えるECS Anywhere
また追加料金の部分にも注目してみましょう。MediaLive Anywhereではオンプレミスインスタンスの認証と登録にAWS Systems Manager Agnet (SSM Agent)が必要となるそうです。このSSM利用の際、アカウントごと、リージョンごとに1,000を超えるインスタンスある場合はSSMの料金が発生するとのことです。この追加料金の設定、ECS Anywhereと同じですね。
続くもう1つの追加料金についても確認します、VPNまたはDirect Connect経由で行われるECS AnywhereコントロールプレーンとECSエージェント間の通信に対して、AWSデータ転送料金が発生するということです。なおこれら通信がオープンインターネット経由で発生する場合はデータ転送の課金は発生しません。ECS Anywhereについての記載がありますね。そしてこの文言も、ECS Anywhereの追加料金と同じものです。
本エントリ後半でリソース作成の際にも確認しますが、MediaLive AnyhwereはどうやらECS Anywhereと連動して動作するようです。
MediaLive Anywhereの使用開始までの雰囲気をつかむ
MediaLiveの新機能MediaLive Anywhereの概要などについて確認してきました。とても興味深いMediaLive Anywhere、さっそくやってみた!といきたいところですが、上記のようにハードウェアの制限などがありそうなこと、また(もしかしたら推奨ハードウェア以外でも動作するかもしれませんが)検証用ハードウェアの準備がすぐにできそうにないことから、今回のエントリでは実際に動作させてみることは断念しています。
代わりに、MediaLive Anywhereで新たに登場したリソースの作成などを通して使用開始までの雰囲気を掴んでみます。AWSマネジメントコンソールをみてみると New の表示とともに、Medialive Anywhere用の項目が並んでいますね。
AWS Elemental MediaLive UserGuideの以下項目も参考にしながら、各リソースについて確認していきましょう。
MediaLive Anywhere用IAMリソースのセットアップ
MediaLive Anywhereを利用する際、MediaLiveが実行されているオンプレミスハードウェア(これをNodeと呼びます)でMediaLiveとAWS Systems Managerのアクションが実行できるよう設定する必要があります。この設定のためのIAMロールを作成しておきます。
User Guideの以下ページを参考に進めます。
まずはIAMポリシーの作成です。以下のポリシー内容でMediaLiveAnywhereAccess
という名称のIAMポリシーを作成します。AWSアカウントID部分は適切な値に変更しましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"medialive:submitAnywhereStateChange",
"medialive:pollAnywhere"
],
"Resource": "arn:aws:medialive::111122223333:cluster:*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/MediaLiveAccessRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"medialive.amazonaws.com"
]
}
}
}
]
}
続いてIAMロールを作成します。Trusted entity typeでCustom trust policy
を選択し、ポリシー内容として以下を設定します。Add permissionでは先ほど作成したMediaLiveAnywhereAccess
ポリシーを選択、Role nameをMediaLiveAnywhereInstanceRole
としてIAMロールを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": ["medialive.amazonaws.com", "ssm.amazonaws.com"]
},
"Action": "sts:AssumeRole"
}
]
}
作成したIAMロールをのちほどCluster作成時に指定するので、ロールARNをメモしておきます。
またMediaLiveのChannelリソースに設定する、デフォルト名称がMediaLiveAccessRole
のIAMロール(MediaLive trusted entityと呼ばれるようです)についてもsts:TagSession
Actionを追加するよう編集しておきます。
Trusted relationshipの項目を確認します。変更前は以下の内容でした。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "medialive.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Actionでsts:TagSession
を追加します。以下の内容になりますね。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "medialive.amazonaws.com"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
MediaLive Anywhere用リソースの作成
続いて、MediaLive Anywhere用のリソースを作成していきます。今回はNetwork、Cluster、Node、そしてChannel palacement groupを作成してみました。なおいずれも リソース作成自体を主眼においており、動作させるための設定とはなっていない ことにご注意下さい。
Networkの作成
まずはNetworkを作成します。NameのほかにIP PoolsとRoutesを設定するようです。今回、正確な要件などがわからかなったため、仮でIP Poolは10.0.14.0/24
、RoutesはCIDR 10.9.0.0/16
、Gatewayは10.9.0.1
を指定してみました。
Clusterの作成
続いてClusterを作成します。Cluster nameのほか、Instance role ARNを指定します。先ほど作成したIAMロールをロールMediaLiveAnywhereInstanceRole
のARNを入力しましょう。
Network settingsでLogical interface nameを適切に入力、Network nameで先ほど作成したNetworkを指定します。Default routeは候補で現れたLogical interfaceを設定してみました。このNetwork settignsの項目についても正確な要件などが現段階で把握しきれなかったため、リソース作成を優先して仮の値で設定をしています。
Nodeの作成
Cluster作成後の画面から[Create node]ボタンでNodeを作成してみます。Nameを適切に入力、Node roleはActive
またはBackup
から選択可能です。今回はActive
を選択してみました。Logical interfaceはClusterで作成したものが候補に現れているので選択します。Physical intarfaceの項目については、「Physical interface name must be a valid Linux interface name.」という要件があるようですのでeth0
としてみました。Interface modeはNAT
またはBridge
が選択できます。今回はNAT
で進めてみました。
[Create]ボタンを押下すると以下のような画面になります。Nodeと関連付けたいハードウェア上でrootとして2つのスクリプトを実行せよ、とのことですね。
1つ目のスクリプトは「MediaLive Anywhere Node Registration Script」と称されたものでした。2つ目はECS AnywheredでExternalインスタンス登録のスクリプトと同じものですね。(例えば「Amazon ECS Anywhereを使ってAWS外でもコンテナが運用できるようになったので使ってみた | DevelopersIO」でも、同一のスクリプトの実行が確認できます。)料金確認の際にも少し触れましたが、MediaLive AnywhereではECS Anywhereをオンプレミスインスタンスの管理として利用しているようです。
このあとは実際のハードウェア機器上で上記2つのスクリプトを実行、それによって実際にNodeに実際のハードウェアが関連付けられる、という流れになるかと思いますが、本エントリではハードウェア機器の準備などができなかったので登録までは行いません。
なお、この段階でAmazon Elastic Container Serivce (ECS)のマネジメントコンソールを確認してみると、以下のようにMediaLiveAnywhere
という名称のCluster、またMediaLiveAnywhereAgentCluster-clusterId-XXXXXXX
という名称のServiceとTask definitionsが登録されていました。
Channel placement groupの作成
Channel placemnet groupについても作成だけ試してみます。Cluster詳細画面のChannel placemnet groupsの項目、[Create]ボタンから進みます。
Channel placement group nameを適切に入力します。Nodeの選択が可能ですが、先ほど作成したNodeはREGISTERING
状態で選択できません。今回はNone
のまま[Create]しました。
MediaLive AnywhereなInputの作成
MediaLive Anywhere用のリソース、NetworkとCluster、NodeとChannel placement groupの作成を確認してきました。続いてはMediaLive Anywhereで使用する想定のInputを作成してみます。通常のInputリソース作成と同様に[Create input]ボタンから進みInput nameを適切に設定、Input typeはRTMP (push)
としてみました。
続く設定項目を確認してみます。Input network locationという設定項目が増えていますね。デフォルトはAWS
ですが、On-premises
を選択してみましょう。
On-premises network settingsの項目が現れます。先ほど作成したNetworkリソースを設定してみます。Advanced settingsではStatic Ip addressとNetwork Routesが設定可能ですが、今回はデフォルトの無指定のまま進めます。
Input classはSINGLE_INPUT
としてInputを作成しました。
MediaLive Anywhereで利用する想定のInputが作成できました。Input network locationがON_PREMISES
となっていますね。そしてEndpoints URLのIPアドレスは10.0.14.123
と、作成しているNetworkリソースのIP Poolsから1つが割り当てられています。Input security groupsが設定されていないのも特徴ですね。
MediaLive AnywhereなChannelの作成
続いてMediaLive Anywhereでの利用を想定したChannelリソースについても作成してみましょう。こちらも通常のChannelリソース作成と同様に[Create Channel]ボタンから進み、Channel templateでLive event (HLS)
を選択しました。Channel nameとIAMロールも適切に設定しましょう。
Channel templateの項目の下にMediaLive Anywhere settingsという項目が追加されています。(これはMediaLive Anywhere用のリソースを作成することで出現するようです。MediaLive Anywhere用リソースが存在しない状態では表示されませんでした。)ClusterならびにChannel placement groupで、それぞれで先ほど作成したリソースを選択しておきます。
Input attachmentsに進みます。先ほど作成したMediaLive Anywhere用のInputを選択しましょう。ここではLogical interfaceの選択項目も現れます。先ほど作成したものを選択してみました。
Output groupsの設定、出力先URLは仮でhttp://10.9.0.15/medialive-anywhere-test-channel-output-groups/index
としておきました。MediaLive Anywhere SettingsとしてLogical interface nameの選択項目がありますので、作成済みのリソースを選択しておきます。
動作を想定したものではありませんが、MediaLive Anywhereの設定を行ったChannelが作成できました。MediaLive Anywhere settingsとしてClusterやChannel palcment gopusなどが関連付けられていることが特徴かと思います。なお、Nodeが登録されておらず、実行できないことはわかっているためChannelのStartまでは試していません。ただ雰囲気としては、このままChannelをStartすることでオンプレミス側リソースでMediaLiveのライブ動画処理がはじまるものと思っています。
まとめ
AWS Elemental MediaLiveの新機能、MediaLive AnywhereについてAWSのブログポストやドキュメントなどからわかることをまとめつつ、関連リソースを作成し動作の雰囲気をつかんでみました。ライブ動画の処理について、クラウドにはElemental MediaLiveがありつつも、オンプレミス側で処理をしたい場合にはElemental Liveかなと思っていたので、このMediaLive Anywhereは「そうきたか!」とびっくりしました。アップデートブログ(Introducing AWS Elemental MediaLive Anywhere: Cloud-controlled live video encoding on your own infrastructure | AWS for M&E Blog)で引用されている、AWS Elemental GM、Manish Raoさんの「“When you can’t get your live video sources to the cloud, MediaLive Anywhere brings the cloud to you,”」という言葉が印象深いですね。
本ブログエントリでは事情により実際にMediaLive Anywhereを動作させるというところまでは確認できませんでしたが、リソースの作成を通してECS Anywhereと連携していることが確認できました。ほかサービスとの連携、非常にAWSらしいですよね。ECS Anywhereとしては仮想マシンなどいろいろな環境下で動作するかと思います。MediaLive Anywhereについても推奨環境以外でも動作させること自体はできるかもしれませんね。追って検証してみたいと思います。
ほかにはAmazon ECS Anywhere、Amazon EKS Anywhere、IAM Roles AnywhereがAWSでAnywhereと名がつくサービス・機能である認識です。(もし漏れていたら教えてください。なお筆者は当初、IAM Roles Anywhereがでてきませんでした。教えてくれた同僚に感謝です!) ↩︎
さらにいえば「AWS Elemental Link」もありますね。こちらはElemental MediaLive専用のデバイスでしたが、最近一部デバイスはAWS Elemental MediaConnectにも接続できるようになりました。 ↩︎